In software engineering, testing is an integral part of the development cycle of an application or software. For this, testing an application or software involves generating test cases where each test case tests a certain functionality of the application or software. Often this involves invoking other aspects of the application or software. Code or scripts are written to develop each test case based on a specific test case logic/scenario. Further, scripts can be written to automate the testing process. However, writing individual testing logic for each test case often becomes a laborious and time consuming process. Furthermore, maintenance of automated test cases or test suites designed with traditional methods are also time consuming as any changes in functionality of Application Under Test (AUT) requires update/modification of multiple test case scripts.
FIG. 1 is a block diagram illustrating automated testing of an AUT using known traditional methods. Referring to FIG. 1, framework 102 includes framework engine 104 interacting with the framework library 106. Framework library 106 includes functions or procedures provided within a framework function library 108 where all the functions needed to test an AUT are provided. Test repository 110 includes one or more test suites 112. Each test suite 112 includes scripts/code logic for one or more test cases 114, each test case 114 testing a functionality or aspect of the AUT. In traditional methods, function library 106 is directly used (called) from test case 114 script of a test suite 112.
Framework 102 represents a general test automation framework including three main components, framework engine 104, framework library 106 (representing a collection of framework function library 108) and a test repository 110. The framework engine 104 represents the main script that configures environment for execution, runs the test suites 112 which represents a sequence of test cases 114, and is responsible for the output results or reports of test execution. The framework library 106 includes framework function library 108 which represents a collection of scripts that cover general functions or procedures required by the test cases/scenarios (e.g. data transformation, search processing, common command execution with parameters, etc.). With traditional test automation methods these functional scripts are utilized within test case's scripts to partially eliminate redundancy of the code.
The test repository 110 represents a collection of automated test cases usually grouped by test suites 112 to assist in maintenance. A test suite 112 represents a container for test cases 114 that are used for testing specific functionality, or a specific aspect of the AUT. Usually, grouping test cases 114 in test suite 112 helps in maintenance and planning for test coverage. However, such maintenance and planning can be limited in large scale application development if a functionality or aspect of the AUT changes during development.
Traditionally, test automation of heterogeneous software products (components) was developed separately utilizing appropriate tools (frameworks). Such approach is limited to testing homogeneous software products (or functionalities) within single test case and does not support complex test scenarios. For example, test automation frameworks designed to work with distributed test environment (over the network) through command line interface (CLI) does not support testing software products through graphical user interface (GUI), and test automation frameworks designed for GUI testing has very limited support for CLI and remote, over the network, execution.